Feb 1996 How-To Columns

by: Eric Carr

YOU MEANT WELL. Remember all those New Year's resolutions you made last month--to do more with less, to take a more proactive approach with users, to work smarter, all while migrating your desktop population to Windows 95? Well, don't give up on them just yet: The year is still young. This month, I'll tell you about some Windows 95 administrative tools that will help you meet your productivity resolutions.

In recent columns, I've detailed some tools to help you control the Registry, the foundation of Windows 95. Now I'll explain how to set up the network underpinnings for remote control and administration, and then show you how to use these tools to administer remote computing platforms over the network.

First, the nuts and bolts. Installing and configuring all the pieces to prepare your desktops for network administration is essential. To do this, you've either got to install Win95 correctly the first time or run around to all your organization's desktops and set things up manually. I recommend you invest the time it takes to learn all about install scripts, so you can set up multiple desktops with the same configuration. It will take time to get used to the workings of MSBATCH.INF, the install script, but it will ultimately save you footwork.

You must do four things to get your desktops ready for remote administration. The first three are essential; nothing will work unless you complete these tasks.

Enable user-level security. You must enable this feature on each network machine. User-level security allows a domain host to authenticate access to a shared component on the local Win95 machine. This could be a printer, a directory on a hard drive or the local machine's Registry. Domain hosts can be either Windows NT or NetWare servers.

Install the remote administration component. Each machine must have the remote administration component installed and available for use during normal operation. The remote component provides the necessary connectivity and authentication facilities Windows 95 needs to provide remote administration functionality.

Run a common transport protocol. It doesn't matter if you're running TCP/IP, NetBEUI, IPX/SPX or any combination of the three. What matters is that all the computers you manage have at least one transport protocol in common. No need to specify which protocol is necessary; Win95 will figure it out for you and use the one that connects the most machines.

Use File and Print Sharing. Now that you've completed the first three tasks, evaluate whether you want to run File and Print Sharing services on each network machine. This feature allows users on one machine to access the file system on, and printers connected to, another. Win95 has some optional tools that will operate only when this peer-to-peer service is running, particularly the NetWatcher program, which you may find useful. File and Print sucks up CPU and memory cycles on every machine it runs on, though, so you'll need to decide if the ability to run NetWatcher is worth it. You'd best try it out on several machines before you decide to deploy it on every machine.

Once you've installed and enabled all the basics required for network control, it's party time. In previous columns, I've shown you how to install and load both the System Policy Editor and the Registry Editor. Using these tools to examine network resources is a breeze. In the Policy Editor, select File/Connect and enter the computer's name as it appears in the Network Neighborhood. Assuming you have the appropriate permissions, the Remote computer's Registry will be displayed. In the Registry Editor, select Registry/Connect Network Registry and enter the name of the machine to be administered. Once connected, the remote device's Registry will appear below the local machine's Registry.

Now let's look at a new tool: the System Monitor. Install System Monitor via the Add/Remove Programs icon in Control Panel. Choose the Windows Setup tab, select Accessories from the Components list and click on Details. In the list, make sure System Monitor is checked, then click on OK. If the program isn't already installed, click on OK again to do so. To run the program, select Start/Run and enter sysmon. By default, System Monitor displays the status of the machine it's running on. To monitor a remote computer, select File/Connect and enter the computer's name. Note that multiple instances of the program can run simultaneously, each monitoring a different computer.

System Monitor graphically displays the value of different Registry components in real time. Because the program is designed as a monitor, it has no inherent ability to change any settings it's monitoring. And the items it monitors depend on the machine's configuration. These items include the file system, kernel, memory manager, network client, certain protocols, file and print statistics, and basic network traffic through the network adapter. Each item has multiple components that can be monitored. For instance, if you suspect you don't have enough memory to run a particular application set, you can display all the memory-manager components together to get a complete picture of memory management as the application executes (or tries to execute).

So, you can use System Monitor to locate a problem's cause when you suspect something's wrong, and it will point you in the direction of a solution. Compare this ability with the System Policy Editor and the Registry Editor. The latter two are better suited to making changes in the configuration of the machine (or machines) in question.

Now that you have an additional tool to increase your productivity, you can make good on at least one of your New Year's resolutions. Next month, I'll tell you more about another tool, the NetWatcher, and try to put all these tools in perspective.

The table below lists the tasks required to prepare a machine for remote administration and describes how to accomplish those tasks, either before or after you install Win95. Choose whichever course of action works for your installation.

Task
Enable user-level security

Via an installation script (MSBATCH.INF)
Security=server or domain

PassThroughAgent=servername

In the [Strings] section:

Server_Domain_Username =servername\administrator

Use the INF Installer (INFINST.EXE) with the REGSRV.INF information file to modify MSBATCH.INF.

After You've Installed Win95
In Control Panel, click on the Network icon and select the Access Control tab. Select User-Level Security and enter a password. You can use the same password or a different password for each machine. You'll trade simplicity for security if everyone has the same password, so decide which is more important to you.

Task
Install the remote administration component

Via an installation script (MSBATCH.INF)
In the [Network] section:

services=remotereg

After You've Installed Win95
In Control Panel, select the Network icon. Click on Add/Select Service/Have Disk, enter the path to the ADMIN\NETTOOLS\REMOTEREG directory and click on OK. Click on OK again, then choose the Remote Registry in the Select Network Service dialog box.

Task

Ensure a common protocol is running

Via an installation script (MSBATCH.INF)
protocols=mstcp and/or netbeui and/or nwlink and/or nwnblink

After you've installed Win95
In Control Panel, select the Network icon, click on Properties and select a protocol. The protocol must be the same for each computer in your monitoring scheme.

by: John D. Ruley

If you still have my Comdex presentation, you'll find all the data you need on the sheet labeled Slide No. 4. Look at the figures for the Shell Preview and the Multi-Protocol Router (MPR) betas. The Alpha was the most popular RISC version downloaded, accounting for just 2.2 percent of the Shell Preview downloads and 6 percent of the MPR downloads. Given that Digital only recently announced the shipment of its 100,000th Alpha, this places an upper bound on NT's installed base. If 100,000 Alphas account for 2.2 percent of NT's installed base, it can't be more than 4.5 million.

As a cross-check, I took another look at the mail I get from the Internet's LANMAN-L (LAN Manager and NT Server--mostly NT Server these days), WINNT (NT Workstation and Server) and WEBSERVER-NT (NT on the Internet) mailing lists. Just looking at the message counts isn't terribly useful. The three lists total around 1,500 messages per month, which does tell me one thing--there are a lot of NT users. But looking at the number of new users who post on the lists each month reveals a fourfold growth rate over the past five months.

My earlier published estimates indicated NT's overall installed base exceeded 1 million at the beginning of this year; one Microsoft executive admitted as much in a speech. Plug that into a fourfold increase, and you get an installed base of 4 million.

Although Deep Dark knew about the CompuServe downloads and mailing-list counts, he couldn't have known about some proprietary information we just received: a study of you, the readers of WINDOWS Magazine. It tells us some 8 percent of you are running NT. If this figure is representative of the active Windows installed base, which is at least 50 million, that, too, places NT's installed base at about 4 million.

All three approaches--none of them statistically defensible--agree NT's installed base is around 4 million. That's close to half the size of the Windows 95 installed base of about 10 million as of this writing. And although I can't be sure my logic is correct, the fact that three different approaches produce similar results makes me confident I've got the magnitude about right.

That ought to be good news for the folks at Microsoft, so why aren't they bragging about it? Unlike me, the NT product managers at Microsoft don't have to guess, or try to extrapolate an installed base from statistically questionable information--they know exactly how many copies of NT are out there. If you have any ideas on why they aren't talking, drop me a line, because I'm stumped. In the meantime, if you're running NT, at least you no longer need to feel lonely.

"Coooooooooeeeeeeeeel!" That's my good friend and colleague Jim Forbes' favorite expression. I don't like to use it, but in this case I'll make an exception.

... Digital's FX!32. This product could change the whole ball game for NT on RISC. It's a binary translator (not emulator) that converts 32-bit Windows binaries for Intel processors (read: Windows 95 applications) to native Alpha binaries automatically on program load. Digital demonstrated the product running the Win95 versions of Microsoft Word and Excel. The performance isn't on par with a native recompile of an application specifically for the Alpha, but it's close; Digital's placing it at 40 to 70 percent of native performance. Best of all, Digital plans to offer FX!32 free to Alpha users. Check Digital's Web page (www.digital.com) for more information.

As I mentioned, one PC maker now does half its business on NT--and the bulk of that is coming at the expense of NetWare. True, NetWare 4.1 is an impressive product, but if Novell wants to retain its lead in the network business, it had better rethink its licensing strategy. The company won't license its multiprocessor version to third parties on anything other than an OEM basis. So only the largest server vendors can ship multiprocessor NetWare, which puts it at a significant disadvantage to NT Server. Pretty bogus, Novell.

Our new Enterprise Windows section debuts in this issue. You'll find a review of two powerful NT-based CAD workstations, WINDOWS Magazine columnist Martin Heller's take on OpenGL accelerators, an article on NT batch files and more. This section will appear periodically, so you can look forward to more NT coverage than I can cram into this column.

1. Set up TCP/IP--just the protocol and the simple services

(ftp, telnet and ping).

2. Set up RAS for client (dial-out) access.

3. For dialing in through CompuServe only, edit the WINDOWS\SYSTEM32\RAS\SWITCH.INF file. Add the following lines just before the Additional Examples section:

;===========================================

[Compuserve PPP Login]

; Modified from Generic Login for CIS dial-in PPP

; Start communication with remote computer by sending COMMAND=

COMMAND=

; Send <cr> to wake up the host

COMMAND=<cr>

; wait for ": "

OK=<match>": "

LOOP=<ignore>

; respond with "CIS" to get into CompuServe

COMMAND=CIS<cr>

; wait for ": "

OK=<match>": "

LOOP=<ignore>

; respond with username from RAS authentication window

COMMAND=<username><cr>

; wait for ": "

OK=<match>": "

LOOP=<ignore>

; respond with password from RAS authentication window

COMMAND=<password><cr>

; wait for "!"

OK=<match>"!"

LOOP=<ignore>

; respond with "go pppconnect" to get into PPP

COMMAND=go pppconnect<cr>

; wait for "..."

OK=<match>"..."

LOOP=<ignore>

; connection should be complete

; ignore the final responses

OK=<ignore>

4. Start Remote Access, then add a new phone-book entry named PPP. Enter your local ISP's access number (for CompuServe, use the regular local access number) as the phone number. Click on the Network button and select PPP/TCP-IP, then TCP/IP Settings. You want a Server-assigned IP address, but depending on how your ISP is set up, you may need to key in the DNS server address manually. (For CompuServe, it's 198.4.7.1). Click on OK to get back to the Edit Phone Book Entry dialog.

5. Click on the Security button.

a) For CompuServe only, select Accept Any Authentication Including Clear Text, <None> as the before-dialing script, and CompuServe PPP Login as the after-dialing script. If you can't get CompuServe PPP Login, exit RAS, check the additional lines you added to SWITCH.INF in step 3 and try again.

b) For other ISPs, select Use Clear-Text Terminal Only and <None> for both the before- and after-dialing scripts. Later, you may be able to hack a SWITCH.INF file similar to the one for CompuServe in step 3. (See the Remote Access help file for details.)

6. Click on OK until you get back to the Edit Phone Book Entry dialog. Remove the check from the Authenticate Using Current User Name And Password box and click on OK.

Now, all you have to do to get a direct PPP is dial PPP. If you're using CompuServe, enter your CIS ID as the user name and then your CIS password. You can leave the Domain field blank. RAS will dial in, and once it gets a connection it will execute the script from step 3. This will log you on and execute the GO: PPPCONNECT command. If you're using another ISP, you'll get a terminal window that will let you enter whatever commands are necessary to log onto the ISP's system (you'll have to get details from the ISP). Click on Done to complete the connection.

by: Martin Heller

LIFE EVENTS HAVE a way of jarring you out of ruts. Some months ago I had a son, who reminds me daily of life's essentials: a warm bed, a dry diaper, plenty of milk.

More recently my cat, Mr. Badger, died suddenly. My grief over the loss of this friend again brought me back to basics, and even pushed me into reviewing the fundamentals of my work.

While I've been off in the stratosphere tracking new and advanced areas of Windows programming, there's been a big shift at the basic level: the Microsoft Foundation Classes (MFC) have become a de facto standard. Oh, you can still write Windows programs at the API level, but for most new applications, MFC offers coding convenience and more features. The demands of high-performance server applications, however, may force you to work at the API level.

This brings me to MFC basics. If you have a copy of a C++ compiler with MFC, take this test. Generate an application to use the framework (with AppWizard if you're using VC++), then modify the application to display Hello, World in the center of the main window, or in the center of each multiple document interface (MDI) child window if you chose to generate an MDI application. If it takes you more than 10 minutes, pay attention to the rest of this column.

My students find this Hello, World exercise to be harder than it sounds because they have to learn a lot about what goes where in MFC's model. They also need to learn the subtleties of using Windows' graphical interface (GDI).

I'll start with the framework issues. MFC follows a document-view-frame model. An MFC document class knows about your data. It could be data in memory, some algorithm for generating data or some way of retrieving information from a remote database. The term "document" here is intended to be an abstraction and means pretty much the same as "model."

The MFC frame class knows about window frames (everything outside your client area). The MFC view class manages the interaction of the document, the frame and the user. The base view class CView inherits from CWnd, the base class for windows, so it can easily construct a display context (DC) and draw in a window.

The view class also has a member function, GetDocument ( ), which can quickly get a pointer to the document class associated with the view. A document template class manages the creation of a view and its associated window frame and document classes. The term "document template" is confusing. It refers to a specific C++ class, not to the C++ language template feature used to generate function families for different data types.

The bare framework application created by AppWizard contains an application class derived from the MFC CWinApp class, a frame class drawn from CFrame-Wnd, a view class from CView and a document class from CDocument. In such an application, the most appropriate place to put code that draws in a window is not an OnPaint handler function, but the OnDraw member of your view class.

That threw me at first. In SDK programs, painting is done in response to a WM_PAINT message. Using MFC you can handle WM_PAINT in any class derived from CWnd, including both frame and view classes. However, the default CWnd: : OnPaint member constructs a CPaintDC object and calls the view's OnDraw member, passing it a pointer to the paint DC. In effect, the OnPaint method is calling BeginPaint and EndPaint for the OnDraw method. That leaves the OnDraw code independent of its device context, so you can often call the same OnDraw method to render into printer and metafile device contexts.

That's a worthwhile trade-off, because you get printing and print preview functionality in WYSIWYG applications without doing any coding. Properly placing your code makes all the difference.

Knowing where to put the code is only half the battle. You also need to know what code to write. Although the basic scheme for painting with Windows' GDI is convoluted, it's not really difficult. Get a DC, create the drawing tools you need--pens, brushes, fonts and so on--and select the tools into the DC. Do your actual drawing--of lines, curves, text and filled regions--changing tools as needed, and then release all your drawing tools and your DC.

Unless you're doing something interactive, such as drawing a rubber-band box, you normally repaint a screen region only when it becomes invalid, which can be triggered by window movement or a change in the underlying document. In the former case, Windows sends you a WM_PAINT message, while in the latter case you need to call InvalidateRect or Invalidate to tell Windows to generate the WM_PAINT message.

If a view changes the document, it's responsible for calling UpdateAllViews so the framework can notify all the other views of the change. The notification comes to each view's OnUpdate member, which is responsible for calculating the invalid rectangle on the screen and notifying Windows. The view that made the changes in the document doesn't get such a notification, because it knows it made a change.

In rendering to a screen or other device, the DC, which connects the relevant device driver to GDI, is of prime importance. Every GDI call in the SDK has the DC handle as its first parameter. In general, Windows provides a handle for something a C++ programmer might call an object. What could be more natural than a class for DCs? This class is called CDC. To do any rendering, call the appropriate member function of CDC. For instance, to draw text, you might call CDC: : TextOut or CDC: : DrawText. In the OnDraw method the code to say Hello, World would be pDC>TextOut(x,y,csHello), where csHello is a CString object initialized to Hello, World.

That raises another question: How do you center the string in the window? One way to do it is to find out how big the window is and how big the string will be when it's displayed, do a little math and call TextOut. Another is to use a more powerful function such as DrawText and tell it you want your string centered.

The function that tells you your window's client-area size is GetClientRect. The function that tells you the size of your text is GetTextExtent, while the one that tells Windows whether you want your strings left-aligned, right-aligned or centered is SetTextAlign. Most students can't figure out client rectangles from Microsoft's documentation. They try to get the size from GetViewRect, which sounds like it might be what you want, but it isn't. The confusion stems from logical and physical coordinates, and there's additional confusion between screen coordinates and client coordinates.

The online documentation isn't bad; it's just fragmented. Students new to Windows, especially if they've got experience in X-Windows and Motif programming, think they can just dive in and pick it up. They eventually learn Windows isn't designed exactly like anything else, and they really have to read the manuals' overview chapters.

You used to get a shelf full of books along with the Windows SDK. You'd start at the beginning and read through to the end with a physical book. The overviews are in Volume 1, and if you start at the beginning you'll get the background information you really need. But when you're working online, it's only natural to zero in on the specific information you think you need, and it feels unnatural to work sequentially through the massive amount of material documenting the Windows SDK and MFC.

Despite all the convenience of context-sensitive help and hypertext jumps, that sense of starting at the beginning and working through to the end has been lost in the transition from paper books to online documentation. Maybe magazine columns still have a place in the world, after all.